Extend git flow complex example to post merge and rebase behaviour #4585

9swampy · 2025-06-21T18:19:47Z

Description

Extend the GitFlowComplexExample to document unexpected post merge and rebase behaviour.
Fix the integration test fixtures so they can accept a "master" main branch instead of hardcoding "main".

Related Issue

Motivation and Context

I have been really struggling to get GitVersion to work post the v6 changes so I checked out the repo to run through sample scenarios to try and adapt but I either need more documentation to understand what the new behaviour is or the new behaviour is possibly unintended.

Rather than just rely on the Integration tests with injected configuration, I wanted to be able to revisit the repository that is created by the integration test and I observe

Inconsistent behaviour between the TestFixture and when running dotnet-gitversion against GitVersion.yml output by the test fixture (problem number 1 documented in the penultimate commit in the amended GitFlowComplexExample - I set this assertion to pass but behaviour in the test does not match behaviour observed with dotnet-gitversion 6.3.0 and a persisted GitVersion.yml)
Consistent but unanticipated behaviour on a rebase (problem number 2 which is the current failure in the amended GitFlowComplexExample)

How Has This Been Tested?

GitFlowComplexExample

Screenshots (if appropriate):

Checklist:

This is a WIP proposal to document a problem & ask for help; if I get direction I'm happy to update the PR as offered/advised.

My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.
I have added tests to cover my changes.
All new and existing tests passed.

asbjornu · 2025-06-24T09:46:58Z

@HHobeck, I think these changes look reasonable. What are your thoughts on this?

9swampy · 2025-06-24T19:28:37Z

src/GitVersion.Core.Tests/Helpers/TestBase.cs

@@ -7,7 +7,7 @@ namespace GitVersion.Core.Tests.Helpers;

 public class TestBase
 {
-    public const string MainBranch = "main";
+    public const string MainBranch = RepositoryFixtureBase.MainBranch;


#4589 Magic strings >> BranchConfigurationKey.

May I ask you: Why do you care about how the branch is named in the unit tests? Does it make any different if it is named master or main? From the configuration point of view both are included and treated the same. At the end everyone can use their own name and their own configuration in the unit tests. There is no need for unification IMO.

9swampy · 2025-06-24T19:32:00Z

src/GitVersion.Core.Tests/IntegrationTests/GitflowScenarios.cs

+        fixture.MakeACommit(
+            "feature 2 additional commit after original feature has been merged to develop " + System.Environment.NewLine +
+            $"and release/1.2.0 has already happened >> {fullSemver}" +
+            "Problem #1: 1.3.0-f2.1+0 is what I observe when I run dotnet-gitversion 6.3.0 but in the repo the assertion is 1.3.0-f2.1+1" +


Problem 1:

1.3.0-f2.1+1 is what the test asserts

1.3.0-f2.1+0 is what I observe when I run dotnet-gitversion 6.3.0

I have executed gitversion (6.3.0) after the test step you mentioned and got 1.3.0-f2.1+1:

9swampy · 2025-06-24T19:35:20Z

src/GitVersion.Core.Tests/IntegrationTests/GitflowScenarios.cs

+            $"and release/1.2.0 has already happened >> {fullSemver}" +
+            "Problem #1: 1.3.0-f2.1+0 is what I observe when I run dotnet-gitversion 6.3.0 but in the repo the assertion is 1.3.0-f2.1+1" +
+            "After rebase 1.3.0-f2.1+3 is both what the test asserts and what I observe when I run dotnet-gitversion 6.3.0." +
+            "Problem #2: I expected to get the same before and after the rebase." +


Problem 2:

Before rebase 1.3.0-f2.1+1 is what the test asserts (but not what dotnet-gitversion produces - see Problem 1).

After rebase 1.3.0-f2.1+3 is what both tests and dotnet-gitversion 6.3.0 produce.

I'd have anticipated1.3.0-f2.1+1 both before and after rebase, in this specific scenario.

The status of the repository is not the same and the information Gitversion uses to determine the next version is different:

Before rebase:

After rebase:

What is your point here?

Odd. If I run the test now and flip out to the command line the config that's being persisted by the test is no longer valid for running with 6.3.0 but it works for you? I'll look again when it's a more sensible o'clock.

In the meantime, as I said on my opening post, if my expectations aren't correct then I would like to understand what would be correct.
1 - The merge bumps the root version on the same f2 commit from 1.2 to 1.3; that's an expected change due to changed state, and the +0 resets since there have now been no commits since version source. All fine.
2 - I'd expected the first commit on the branch since the last version bump to be f2.1+1 as the test asserts before rebase. I concur with the test. Dotnet-gitversion 6.3.0 tbc.
3 - If I rebase that commit, yes the whole tree is different but that first commit is no longer considered the first commit on the branch since the version source? I'd not expected that.

How does +1 jump to +3? If there's documentation, point me at it as I do appreciate you've been generous with your time already.

To be fair working out how to configure the majority minor patch bumps work now is what I'd expected to be playing with in the tests, not the CommitsSinceVersionSource idiosyncrasies...

Odd. If I run the test now and flip out to the command line the config that's being persisted by the test is no longer valid for running with 6.3.0 but it works for you? I'll look again when it's a more sensible o'clock.

I have just opend my cmd-shell and executed gitversion in version 6.3.0

How does +1 jump to +3? If there's documentation, point me at it as I do appreciate you've been generous with your time already.

First of all the algorithm calcualtes the next versions by executing the differnt version strategy implementations. After that the highest increment version will be selected. If there are more then one increment with the same value, the newest base version source will be used.

In both cases (before and after the rebase) the version increment of tag 1.2.1 on main wins which will be returned by the TaggedCommitVersionStrategy class. So far so good. We can assure that the base version source is in both cases the same. Please notice that the base version source (commit) is not part of the feature branch but main branch.

The answer why a different commit count is calulcated is based in the following logic (calculating the CommitsSinceVersionSource):

GitVersion/src/GitVersion.Core/VersionCalculation/VersionCalculators/VersionCalculatorBase.cs

Lines 17 to 26 in d282992

protected SemanticVersionBuildMetaData CreateVersionBuildMetaData(ICommit? baseVersionSource)

{

var commitLogs = this.repositoryStore.GetCommitLog(

baseVersionSource: baseVersionSource,

currentCommit: Context.CurrentCommit,

ignore: Context.Configuration.Ignore

);

var commitsSinceTag = commitLogs.Count;

this.log.Info($"{commitsSinceTag} commits found between {baseVersionSource} and {Context.CurrentCommit}");

Before the reabase you have only one commit which differs from the main branch. After the rebase you have three commits who are not part of main (the branch where the base version source was selected).

Hope that answers your question.

9swampy · 2025-06-24T19:38:55Z

src/GitVersion.Core.Tests/IntegrationTests/GitflowScenarios.cs

+                var yaml = new ConfigurationSerializer().Serialize(concreteConfig);
+                const string fileName = "GitVersion.yml";
+                var filePath = FileSystemHelper.Path.Combine(r.Info.Path, "..", fileName);
+                File.WriteAllText(filePath, yaml);


Intentionally writing out the GitVersion.yml to demonstrate inconsistency between UnitTest version calculation and running dotnet-gitversion from the commandline. Refer to 2 problems in commentary.

9swampy · 2025-07-01T00:02:25Z

RepositoryStoreTests.FindsCorrectMergeBaseForForwardMergeMovesOn from

to

to educate myself.

Only draft code but would you consider that an improvement in documentation capability? Could make the test that I've applied it to brittle, but there would be appropriate tests to apply it to?

HHobeck · 2025-07-01T09:18:02Z

Only draft code but would you consider that an improvement in documentation capability? Could make the test that I've applied it to brittle, but there would be appropriate tests to apply it to?

https://gitversion.net/docs/learn/branching-strategies/gitflow/examples

Source
See DocumentationSamplesForGitFlow.cs. To update, modify then run test.

and

https://gitversion.net/docs/learn/branching-strategies/githubflow/examples

Source
See DocumentationSamplesForGitHubFlow.cs. To update, modify then run test.

If you like you can extend the tests with comments (PlantUML) to make it more clear. For me this is the reference which describes the existing branching and merging use cases for the GitHub and GitHubFlow workflow. The Trunkbased workflow needs to be added here IMO.

9swampy · 2025-07-01T22:18:06Z

There's lots of scope for more docs that would be helpful I think; case in hand myself. As you've concurred that what I've been putting in for my own education could be helpful additions I'll likely split off to something more mergeable in the meantime. Had noted the issue asking for some trunk-based docs too.

9swampy force-pushed the ExtendGitFlowComplexExampleToPostMergeAndRebaseBehaviour branch from 1586c8e to 45f96cc Compare June 21, 2025 18:36

This was referenced Jun 22, 2025

Sanitize Participant #4588

Merged

Format the commitMsg so it doesn't break PlantUml #4590

Merged

asbjornu modified the milestone: 6.x Jun 24, 2025

asbjornu requested a review from HHobeck June 24, 2025 09:45

9swampy commented Jun 24, 2025

View reviewed changes

9swampy added 2 commits June 28, 2025 23:25

Facilitate running tests with master as the default main branch.

6f58131

Document unexpected behaviour by extending GitflowComplexExample.

7a8ef76

9swampy force-pushed the ExtendGitFlowComplexExampleToPostMergeAndRebaseBehaviour branch from 45f96cc to 8e1ddbd Compare June 28, 2025 22:25

9swampy added 3 commits July 1, 2025 00:51

Put default branch back to main.

110abbc

Add CommitsSinceVersionSourceList to VariablesProvider.

0e5a247

Add CommitLabelGenerator and additional documentation to tests.

2f23dd0

9swampy force-pushed the ExtendGitFlowComplexExampleToPostMergeAndRebaseBehaviour branch from 8e1ddbd to 2f23dd0 Compare June 30, 2025 23:51

9swampy marked this pull request as draft July 1, 2025 00:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Extend git flow complex example to post merge and rebase behaviour #4585

Extend git flow complex example to post merge and rebase behaviour #4585

Uh oh!

9swampy commented Jun 21, 2025 •

edited

Loading

Uh oh!

asbjornu commented Jun 24, 2025

Uh oh!

9swampy Jun 24, 2025 •

edited

Loading

Uh oh!

HHobeck Jun 27, 2025

Uh oh!

9swampy Jun 24, 2025

Uh oh!

HHobeck Jun 27, 2025

Uh oh!

9swampy Jun 24, 2025

Uh oh!

HHobeck Jun 27, 2025

Uh oh!

9swampy Jun 29, 2025

Uh oh!

HHobeck Jun 30, 2025 •

edited

Loading

Uh oh!

9swampy Jun 24, 2025

Uh oh!

9swampy commented Jul 1, 2025

Uh oh!

HHobeck commented Jul 1, 2025

Uh oh!

9swampy commented Jul 1, 2025

Uh oh!

Uh oh!

	protected SemanticVersionBuildMetaData CreateVersionBuildMetaData(ICommit? baseVersionSource)
	{
	var commitLogs = this.repositoryStore.GetCommitLog(
	baseVersionSource: baseVersionSource,
	currentCommit: Context.CurrentCommit,
	ignore: Context.Configuration.Ignore
	);

	var commitsSinceTag = commitLogs.Count;
	this.log.Info($"{commitsSinceTag} commits found between {baseVersionSource} and {Context.CurrentCommit}");

Extend git flow complex example to post merge and rebase behaviour #4585

Are you sure you want to change the base?

Extend git flow complex example to post merge and rebase behaviour #4585

Uh oh!

Conversation

9swampy commented Jun 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Checklist:

Uh oh!

asbjornu commented Jun 24, 2025

Uh oh!

9swampy Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HHobeck Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

9swampy Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

HHobeck Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

9swampy Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

HHobeck Jun 27, 2025

Choose a reason for hiding this comment

Uh oh!

9swampy Jun 29, 2025

Choose a reason for hiding this comment

Uh oh!

HHobeck Jun 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

9swampy Jun 24, 2025

Choose a reason for hiding this comment

Uh oh!

9swampy commented Jul 1, 2025

Uh oh!

HHobeck commented Jul 1, 2025

Uh oh!

9swampy commented Jul 1, 2025

Uh oh!

Uh oh!

9swampy commented Jun 21, 2025 •

edited

Loading

9swampy Jun 24, 2025 •

edited

Loading

HHobeck Jun 30, 2025 •

edited

Loading